<!DOCTYPE html>
<html lang="zh-cn">
  <head>
    <meta charset="UTF-8">
    <title>Sucha's Blog - Archive for January, 2020</title>
    <meta name="generator" content="MarkdownProjectCompositor.lua">
    <meta name="author" content="Sucha">
    <meta name="keywords" content="suchang, programming, Linux, Lua">
    <meta name="description" content="Sucha's blog">
    <link rel="shortcut icon" href="../images/ico.png">
    <link rel="stylesheet" type="text/css" href="../styles/blog.css">
    <link rel="stylesheet" type="text/css" href="../styles/prism.min.css">
    <style id="site_theme"></style>
  </head>
  <body>
    <div id="body">
      <div id="text">
	   <!-- Page published by cmark-gfm begins here --><h1>Sucha's Blog ~ Archive for January, 2020</h1>
<p><a id="p3"></a></p>
<div class="date">20年1月25日 周六 21:30</div>
<h2>Babun 和 VSCode git.path</h2>
<p>时光轮流转，现在常用的是 Unix Like 的环境，Win 环境反而是少用了，所以 CatetoryLinux 也用来记录 Win 下的东东吧。</p>
<p>话说过年回家收了家人的 Win7 赛扬四核上网本后，我也不知道哪里来的兴趣（也许是键盘真的要比 13 寸的 MBP 好太多），搭建了发布主页的环境，当时就安装了 Git For Windows，配合 VSCode 设置了 git.path 后，用得好好的。</p>
<p>然后觉得 MinGW64 的 shell 太一般了（其实就是指定了 Path 的 cmd），Git For Windows 自带的 Bash 也真的不好用，就开始搜索 Win 下好用的 shell 环境。PowerShell 是先考虑的，但是看到依赖 NetFramework 4.x 我就想算了，养不起。</p>
<p>然后看到了 <a href="http://babun.github.io/">BaBun</a>，虽然是基于 Cygwin 的再次开发，但自动化安装后，用得很不错。配置部分我现在是很少弄了，安装好后，看到自带了 zsh 和 oh-my-zsh 的配置，不得不说很赞。另外就是操作速度要比之前的 Git Bash 好太多，颜色搭配也相当好看，如下图：</p>
<p><img src="https://tva1.sinaimg.cn/mw1024/6f6cc1c0gy1gb94u3o57lj20m80ch414.jpg" alt="babun"></p>
<p>但是不好的地方，在于毕竟依赖了 Cygwin，而 VSCode 无法直接使用 Cygwin 下的 git 来做版本控制，也许是依赖 cygwin dll 的关系吧。</p>
<p>VSCode 团队回复这种情况，说已经对 Git For Windows 做了支持，这种 Cygwin 环境下的不考虑了。其实大家装了 Cygwin 后，是不想再装一个 Git For Windows 了，几乎做同样的事情，太浪费。</p>
<p>不得不说有的人脑洞奇特（没错，是日本人，无贬义），想着将 Cygwin 下的 git 包一层给 VSCode 使用，重点说一下思路，这种封装依赖的思想。</p>
<p>首先建立一个验证环境的逻辑，VSCode 对于版本控制 git 程序的依赖，跟 Win 下普通 cmd 操作 git 是一样的，如果 Win 下普通 cmd 在不知道 Cygwin 环境时，能够正常使用一个类似 git 的工具完成 git 的功能，可以认为这个工具就是 git（版本控制工具）。</p>
<p>这个思路，其实就是封装环境，将 Cygwin 下的 git 及其依赖，封装到这个工具内部。</p>
<p>这里需要选择工具链，需要生成仅仅依赖 Win 下系统原生 dll 的工具链，比如之前已经用过的 MinGW64。我们把 Cygwin 的依赖，环境描述，写到一个 C 源文件里，在源文件里面，调用了 Cygwin 的 bash，跑一个脚本，这个脚本，大概是整理输入的参数并传递给真正 Cygwin 下的 git。Cygwin 的环境，在 bash 拉起脚本的时候，已经建立完成。</p>
<p>这里可以确保在系统的任何地方，调用这个 C 生成的程序，拉起的 Cygwin 环境都是正常的，然后跑脚本里面的 Cygwin 下的 git 操作，就很顺理成章了。</p>
<p>贴一下仓库地址吧：<a href="https://github.com/nukata/cyg-git">https://github.com/nukata/cyg-git</a></p>
<p>话说这种想法感觉跟容器化的想法类似，将依赖封装到一起；跟编程语言里面的闭包思想也类似，将 upvalue 带入到闭包里面。只是头大后碰到了这样的解决办法，佩服之余，也思考学习一下。</p>
<div class="category"><a href="CategoryLinux.html">CategoryLinux</a> / <a href="2020-01.html#p3">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>
<p><a id="p2"></a></p>
<div class="date">20年1月24日 周五 12:53</div>
<h2>庆祝在 Windows 下更新本站</h2>
<p>受益于<a href="../blog/2020-01.html#p0">MarkdownProjectCompositor 支持 Win 7</a>，有了 generator、compositor 的准备，包括 Win 下 Git 的支持，加上我的编辑器是一个浏览器端单文件编辑器，现在可以比较顺利地在 Win 下写 Markdown，并更新博客了。</p>
<p>老早之前，用 Emacs 做 Markdown 编辑器 + 生成器的时候，也是能够支持 Win 的，当时是用 FTP 上传到网站，改换成 cmark-gfm 后，终于又实现了一次。</p>
<div class="category"><a href="CategoryThisSite.html">CategoryThisSite</a> / <a href="2020-01.html#p2">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>
<p><a id="p1"></a></p>
<div class="date">20年1月24日 周五 12:22</div>
<h2>m_net 支持 pull-style API</h2>
<p><a href="https://github.com/lalawue/m_net">m_net</a> 之前只支持设置 callback 方式回调通知，最近的修改是开始支持 pull-style API。弃用 callback 是为了配合 LuaJIT 的使用，因为 LuaJIT 在 C 层 callback Lua，性能非常不好，<a href="https://stackoverflow.com/questions/12329128/luajit-ffi-callback-performance/12435278#12435278">LuaJIT FFI callback performence</a> 有说明，大体上有 x27 slower。</p>
<p>LuaJIT 官网的相关介绍，也是不推荐 C 层 callback Lua，因为 callback 函数是临时分配生成的，性能不好，而推荐用 pull-style API。</p>
<p>所谓 pull-style API，就是一个同步操作的含义，call 一次就拿一次数据这样。</p>
<p>m_net 的修改，是将 callback 这一层，从 C 移到了 Lua 层，Lua 层从 C 层获取事件通知的多个 chann 及其 message，之后在 Lua 层面做 callback，算是避开了从 C callback Lua 这个坑。</p>
<p>这样子修改之后，跟原来提供非 JIT 的 Lua 接口不一致了，考虑到非 JIT Lua 可选用网络通信模型挺多的，比如老一辈的 LuaSocket，比如 Luvit 之类的，索性我就去掉了非 JIT Lua 的接口支持。</p>
<p>修改完后，做了一个简单的压测，对所有 accept 的 chann，发送一个 HTML 包裹的 hello，world，设置了 backlog 100，ab 100 个实例 5000 次试验的结果：</p>
<pre><code class="language-bash"># ab -c 100 -n 5000 http://127.0.0.1:8080/empty

Concurrency Level:      100
Time taken for tests:   0.547 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      530000 bytes
HTML transferred:       65000 bytes
Requests per second:    9134.39 [#/sec] (mean)
Time per request:       10.948 [ms] (mean)
Time per request:       0.109 [ms] (mean, across all concurrent requests)
Transfer rate:          945.55 [Kbytes/sec] received

</code></pre>
<p>感觉还可以。</p>
<div class="category"><a href="CategoryProgramming.html">CategoryProgramming</a> / <a href="2020-01.html#p1">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>
<p><a id="p0"></a></p>
<div class="date">20年1月24日 周五 01:24</div>
<h2>MarkdownProjectCompositor 支持 Win 7</h2>
<p>给家人换了一台性能更好的老笔记本，之前的上网本自然就归我了，赛扬 N3150 4核 4GB 其实不算差，至少现在开着 Chrome 写 Markdown 是很流畅的，然后想着怎么废物利用，比如用来做下载机，但其实我没啥可下载的，用来搞点 Windows 环境下的编程，写点 Markdown 倒是不错。</p>
<p>然后就想着怎么把之前的工程搬到 Windows 上面来，网络部分的先算了，没有 IOCP 也没啥意思，看来看去，LuaJIT 加上 <a href="https://github.com/lalawue/MarkdownProjectCompositor">MarkdownProjectCompositor</a> 是个不错的入口。</p>
<p>即便如此，这次适配也吃了苦头，赛扬 4G 我是不想用 Visual Studio 了，不管是 2012 还是 2015，下个几 G 编译个几百 K，不值得。就搞了个 MingW64，然后下载了一个 Git。</p>
<p>依赖有 cmark-gfm 和 LuaJIT，lfs_ffi.lua 看了一下是支持 Windows 的。可是 cmark-gfm 不能直接在 MingW64 下编译，需要 cmake，搞了一个 win 下的 cmake，可不是随随便便就能生成 makefile 了，MingW 环境下需要这样：</p>
<pre><code class="language-source">mkdir build
cd build
cmake -G &quot;MinGW Makefiles&quot; ..
make
</code></pre>
<p>你没看错，需要指定生成 MingW 下的 makefile，而且冒号内的关键字不能错哦，这一步浪费了我好几个小时。后面的 make 就很顺利了，虽然赛扬 4G 马力明显不足，磕磕碰碰的最后还是给捣出来了。</p>
<p>MingW 环境编译的程序只依赖 Windows 原生库，所以蛮小的。接下来的 LuaJIT 编译有了前面的铺垫，很顺利就生成了。</p>
<p>后面的 2 个小时，浪费在了 compositor 拼接 source 以及生成 html 的过程中，因为在 lua 里面 io.open() 文件时，没有带 b 用二进制的方式，使得在 windows 下换行是 CRLF 的。因为我的 config.lua 也很复杂，WelcomePage 是根据生成的 html 最后做拼接的，这里也要指定用 binary 的方式读写。</p>
<p>最后我还在 compositor 里面加入了去掉 CRLF 以及 CR 的 dos2unix 开关，把原来 Markdown 里面的多余 CR 都去掉了，毕竟 CR 没啥用，会被 HTML 的 tag 忽略的。这段是确保 MacOS 下生成的 HTML 跟 Windows 下生成的一模一样。</p>
<p>再搞了一个 publish_html.bat 脚本，配置好 config.lua 以及目录后，一键生成，就可以看着赛扬 4核慢吞吞地做转换了。</p>
<p>最后把这半天的成果，windows 下的 cmark-gfm、luajit、lfs_ffi.lua，还有一个一键生成脚本，打了一个 zip 包，作为一个 release 发出去了，毕竟不是专业 windows 下的开发，也许以后再换一个 windows 环境，可真的折腾不来了。</p>
<div class="category"><a href="CategoryProgramming.html">CategoryProgramming</a> / <a href="2020-01.html#p0">Permalink</a> / <a href="https://github.com/lalawue/homepage/discussions/categories/blog" target="_blank">Discussion</a></div>
<!-- Page published by cmark-gfm ends here -->
  <div id="foot">2004-<script>var d = new
	Date();document.write(d.getFullYear())</script> &copy;
	Sucha. Powered by MarkdownProjectCompositor.
  </div>
  </div><!-- text -->
  <div id="sidebar">
  </div><!-- sidebar -->
  <script src="../js/prism.min.js" async="async"></script>
  <script src="../js/blog_sidebar.js"></script>
  </div> <!-- body -->
</body>
</html>